1. The Field of the Invention
The present invention generally relates to Web Service policies. More particularly, the present invention provides for a rule-based tool that assists a user in generating a secure policy document by automatically selecting security conditions for the user's general security criteria. Further, the present invention provides for a wizard type tool that presents the user with an easily understandable visual representation summarizing selected criteria of a Web Service policy document.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. In deed, the computers system ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web Services has been a driving force in advancing such communications between systems and is turning the way we build and use software inside-out.
Web Services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (eXtensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication on a Web Service network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., Web Services) at a server computer system (hereinafter referred to as a “service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated the service responds with a response message providing the desired information. Of course, this request/response type communication is governed by various requirements and capabilities defined by both the client and the service called Web Service Policies, wherein each must be conformant to the others policies.
Web Service policies define a framework and a model for expression of those properties as policies. Policy expressions allow for both simple and declarative assertions as well as more sophisticated conditional assertions. Further, some assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentications scheme, transport protocol selection). Other assertions specify requirements and capabilities that have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, Quality of Service (QoS) characteristics). Nevertheless, Web Service policies provide a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner. Typical, Web Service policies define an XML data structure called policy expression which contains domain specific Web Service policy information and a core set of grammar elements to indicate how the contained policy assertions apply. The policy document can be applied to any Web Service or client to secure a Web Service communication.
A key benefit of the emerging Web Service architecture is the ability to deliver integrated, interoperable solutions. Because, however, Web Services provide various services from different business, organizations, and other service providers via the Internet, security issues are a main concern to protect information that is transferred. Accordingly, Web Services protocols have established security standards that describe enhancement to messaging protocols (e.g., SOAP messaging) to provide quality of protection through message integrity, message confidentiality, and single message authentication. For instance, there are mechanisms that can be used to accommodate a wide variety of security models and encryption technologies. Some Web Service security protocols provide a general-purpose mechanism for associating security tokens with messages. Other Web services securities describe how to encode binary security tokens. Specifically, one specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. This particular service also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included within a message.
By themselves, Web Services securities do not insure security nor do they provide a complete security solution. Web Service securities are building blocks that are used in conjunction with other Web Services in application-specific protocols to accommodate a wide variety of security models and encryption technologies. For example, Web Service securities are used in conjunction with Web Service policies for providing a flexible and extensible grammar for expressing capabilities, requirements, and general characteristics of entities in a Web Service-based system.
Defining a secure policy document using the Web Service policies specification is a challenge for even the most experienced Web Service developers. Omitting a specific requirement or capability can result in serious security vulnerability in the system. This results in severe usability issues when trying to use Web Service policies. Moreover, because the extreme extensibility of XML typically used in Web Service policy documents, developers don't always understand exactly what tags they need to put in secure a service. As such, they typically insecure policies, which are susceptible to attack or other malicious use. Further, because the Web Service policy documents are coded XML, there is no quick and easy way to view the properties of the policy document without having to parse through the XML code. Accordingly, those with a limited knowledge of the WS-Policy schema may not be able to fully appreciate or understand the criteria set forth in a policy document.
Accordingly, there exists a need for a tool that can abstract the user from code used to satisfy Web Service policy documents. Moreover, the tool should be driven by rules in order to insure, e.g., optimum security. In addition, the tool should be able to give an easily understandable visual representation summarizing the criteria of the XML based Web Service policy document.